1. Field of the Invention
The invention relates generally to an integrated software development environment providing improved access to real-time production data.
2. Description of the Related Art
In the context of software development, there exists a problem of developers not having access to real-world data concerning the operation of the software they develop. Typically, once a package is developed, it is passed along to an operations part of the enterprise, where it is deployed to customers. When customers encounter difficulties using the software, their point of contact is usually the technical support department. Often, very little information about how the software is performing in the real world ends up reaching the developers, even though operations centers and technical support divisions may have very rich data. This is problematic, because by some estimates, more than 70% of developer time is spent working on currently-developed components such as enhancements, bug-fixes, etc.
Various tools have been developed for use by operations and technical support divisions to help ensure that software is functioning once it is deployed, but the tools are not developer-focused. If developers could access production data, they could be more responsive, effective, and help to develop more stable components.
One attempt to solve this problem has been through the use of an Operations Management Console. Using a management console, an operations manager follows a standardized process of generating bug reports, forwarding them to the developers, and waiting for updates. However, this is not the kind of direct feedback needed by developers. Typically, using this methodology, the developer does not see all of the raw information available, but rather only a filtered subset of the data.
Another attempt at solving this problem has been to have a quality assurance (QA) department do testing in a simulated real-world environment, sending the sample data to the developers for review. However, because this typically happens after the developer is already finished development for the product and has moved on to something new, no updates can actually be made until the following release of the software. Further, since the data is not actually real-world data but rather is simulated data, it often does not reflect all real-world characteristics. Thus, this solution is not an optimal one. A solution is needed that will provide developers with access to production metrics in the context of an IDE.
Software development involves the creating of computer code related to business logic as well as to non-business logic, i.e. operational considerations. Business logic is a term understood by those of skill in the art, and refers generally to functionality related to the underlying purpose of the software application. For example, suppose that a particular application includes functionality to enter purchase order information into an order management system. That functionality is supported both by business logic, e.g., updating order status, releasing product to shipping, etc., and by non-business software logic, such as code related to ensuring security, error handing, logging, etc. A problem in the art is the difficulty in making changes to business-logic related code that then requires additional overhead to comply with required policies in effect.
When building a web service or distributed application, a developer's first approach may be to embed each component with its own security and other operational management functionality by adding code individually, on a case-by-case basis. This traditional approach can actually add cost, time and complexity over the service's lifecycle. Potential costs include:                Introduction of potential security holes        Replication of similar functionality for every service        Increases in education and training requirements when implementing new standards        Reliance on ad-hoc approaches to visibility of policy compliance        Increases in complexity and cost when updating or extending operational functionality        
Accordingly, there is a need for a system and method for separating the development of software code relating to business logic from operational logic.